加速和保护对大型数据集的GPU访问（SCADA）
核心观点
重新思考现代数据中心的接口设计
大规模：单一API实现规模无关的数据访问 可用于以往无法实现的场景，例如单个节点处理10TB数据，避免内存溢出（OOM）问题 透明地扩展数据集大小和计算集群规模 更高的抽象度：“无服务器访问”是现代数据中心的方式 前端：处理缓存，避免分区，与多GPU/多节点通信 后端：应用程序访问数据集X，将数据存储的位置/方式细节交给其它组件处理 数据平台工具能够管理数据的整合、局部性、分片、预处理阶段 通过最优地利用GPU线程、内存管理和拓扑优化的通信来加速 易于启用：底层接口，不改变应用程序层 从根本上降低TCO：减少存储数据的成本 巨大的数据量 --> 巨大的内存需求 --> 巨大的成本 计算复杂度低的应用程序仅将HBM用作内存而非计算 成本低廉的NVMe使数据中心更加高效
-----
在提供大量数据给GPU时，我们需要支持对数据集高达10万次的精细GPU访问，这些数据集因规模庞大已不再适合存储在内存中，同时我们还要确保对GPU的访问安全无误。新的应用程序，如GNN和VectorDB，从每个GPU线程发出精细化的数据请求，这些请求的数据量远超许多节点的内存容量。
为了提升数据访问效率，我们推出了规模化加速数据访问（SCADA，SCaled Accelerated Data Access）这一新型编程模型。它不仅能有效避免内存溢出等错误，还通过利用NVMe技术降低了总体成本。然而，将存储资源共享给多个租户也带来了安全风险，数据可能遭受来自被劫持计算节点的攻击。
为缓解这一安全威胁，我们将存储驱动程序从不受信任的计算节点迁移至更为安全的DPU。我们进一步介绍了兼具安全性和高性能的安全存储技术。接下来，我们将展示基于cuGraph和SCADA构建的端到端FSI解决方案，该方案不仅大幅提升了性能，而且通过单个GPU就能保护多客户端的安全性，相较于众多未充分利用的昂贵节点，具有显著优势。
此外，我们还将展示如何在DPU上利用全新的基于GDS的0拷贝安全存储堆栈，有效保护传统存储免受攻击。
Source: https://www.nvidia.com/gtc/session-catalog/?search=S62559&ncid=em-even-124008-vt33-23spring#/session/1696360755999001lFr4
在Scale-up和Scale-out时的新考虑因素
大规模数据
大规模数据集无法保存在单个GPU或多个节点的内存中 --> 使用NVMe
无法通过加载和存储访问所有数据 --> 需要新的API KV/对象存储作为访问数据的一种方式越来越受欢迎 --> 为对象定制API 应用程序跟踪的数据太多 --> Serverless,，与数据集服务，编排 大规模集群 静态分区资源效率低下 --> 使用共享计算和存储资源以及安全性 不信任计算资源 --> 将关键操作转移到受信任的基础设施控制平面
使用代理反弹缓冲区时性能不佳
缺点 - 可通过在DPU上使用用户空间客户端来避免 VFS需要本地地址，要求在DPU代理中使用反弹缓冲区 吞吐量影响：系统缓存争用 延迟影响：存储和转发，中断 CPU利用率影响：主机轮询 但可能需要在客户端实现数据
DOCA SNAP virtio-fs是一个运行时DOCA服务和一个DOCA库SDK 一个具有POC的研究项目，尚未列入产品路线图 向主机提供一个受保护的PCI级文件存储端点 从DPU端发起挂载并呈现给主机 - 更安全 隐藏了DPU内的实际文件系统 SNAP存储模拟PCI设备系列的新成员 DOCA SNAP NVMe和DOCA SNAP Virtio-BLK已经存在 支持任何文件存储作为后端 标准Linux内核，如NFS，SMB 内部开发 合作伙伴，供应商 基于SPDK框架和存储堆栈 主机端的GDS（GPUDirect存储） DOCA安全性，零信任，隔离
安全性 零信任，由中心强制执行，更不容易受到供应链攻击 主机不直接暴露于存储网络 通过提供本地存储接口降低攻击面 通过将卷暴露给PF和VF在PCI级别上实现租户隔离 云提供商完全控制：暴露的卷，监控 性能 将与存储相关的CPU周期卸载到DPU 使用DPU加速引擎（CRC，纠删码，AES-XTS等） 减少主机上的噪音 完全支持零拷贝 维护 轻松更新/升级存储服务 轻松更改存储供应商 在内核依赖性方面灵活 对租户透明
简单情况：回弹缓冲区 与从DPU发起的请求执行相同 交叉功能mkey 当DPU发出RDMA时，使DPU能够使用主机地址空间中的地址 无回弹缓冲区 转移仍由DPU服务发起 只有受信任的DPU服务才能访问交叉功能mkey 适用于基于内核的DPU文件系统的零拷贝 需要一种方法将mkey通过VFS传递给POSIX的read（）/write（）系统调用 由DPU上的受信任提供者提供的mkey 被存储客户端使用，攻击面较小，更可靠 每个事务，存储服务器永远不会暴露于整个主机内存 在事务结束时，密钥将被失效
DOCA virtio-fs SDK 随着时间的推移，可能的方法包括： DOCA SNAP virtio-fs基础容器+用户级供应商存储客户端 SOL：轮询，简单的零拷贝，无内核系统调用 通过SPDK API 开始研究：Weka，VAST，DDN Infinia等 Dell，NetApp，Pure对此模型（用于NFS）感兴趣 零拷贝是性能增强 DOCA SNAP virtio-fs基础容器+DPU内核驱动程序 基础容器转发到DPU的VFS 适用于传统内核驱动程序 没有零拷贝 NV用户级容器连接到VFS +链接到启用内核驱动程序的NV库 可以调用NV库以获取零拷贝的密钥 IBM GPFS和Weka已经具有获取GDS的mkey的回调，正在研究此解决方案 使用Kata容器或KubeVirt可以将整个客户端堆栈的DPU保护起来
文件系统供应商 移植并调整为Arm/DPU 将其建模为SPDK驱动程序，并注册到SPDK FSDEV接口 利用SPDK的“内存域”API获取表示主机缓冲区的mkeys，用于零拷贝RDMA传输 内核级解决方案被邀请利用我们成熟的零拷贝内核解决方案 上游化virtio-fs和FUSE 调整主机virtio-fs驱动程序，例如支持多队列以减轻性能瓶颈 探索缓存失效以减轻依赖于用户以O_DIRECT模式打开文件的情况 添加对GPUDirect存储（GDS）的支持，以启用对GPU缓冲区的定位 数据中心/客户 评估安全风险 选择更安全的选项 决定通过对DPUs进行适度的资本支出投资来减少运营支出
两者都使用O（100K）线程加速、计算或IO
海量数据，通过加载和存储无法到达
分区、缓存、通信复杂性
大规模情况下的错误处理存在问题
NVSHMEM用于内存；为内存+存储提供更多内容的新API系列，涵盖任何地方的数据
访问由GPU（或CPU）发起
GPUDirect Async内核发起存储，而不仅仅是GDS
示例：基于读取节点数据的图遍历
大量访问，每个GPU线程1次以上，细粒度带来最大的好处
如何通过PCIe引脚最有效地传输O（100K）个请求/响应？
应用 图神经网络（GNN）- 图+特征存储 1T边的图和数据都无法适应GPU 用于实体和关系的高价值嵌入 推荐和恶意行为检测系统的关键部分 GNN相对于其他嵌入类型提高了准确性 向量搜索/vectorDB - 向量存储 NeMo Retriever，NVIDIA RAFT中的RAG-LLM 数据去重，为训练万亿令牌LLMs做准备与GNN嵌入共同进行的LLM微调受益于庞大的KV服务 cuGraph中提供的图分析： 巨大图上的个性化PageRank、社区检测 用于GNN模型的分布式采样和分区 共同需求：简单管理大于主机+设备物理内存的数据 避免OOM（内存不足）错误 通常需要缓存、分区、多GPU/多节点通信 除非有一个通用解决方案，否则需要为每个应用重新创建
大规模：单一API实现规模无关的数据访问 可用于以往无法实现的场景，例如单个节点处理10TB数据，避免内存溢出（OOM）问题 透明地扩展数据集大小和计算集群规模 更高的抽象度：“无服务器访问”是现代数据中心的方式 前端：处理缓存，避免分区，与多GPU/多节点通信 后端：应用程序访问数据集X，将数据存储的位置/方式细节交给其它组件处理 数据平台工具能够管理数据的整合、局部性、分片、预处理阶段 通过最优地利用GPU线程、内存管理和拓扑优化的通信来加速 易于启用：底层接口，不改变应用程序层 从根本上降低TCO：减少存储数据的成本 巨大的数据量 --> 巨大的内存需求 --> 巨大的成本 计算复杂度低的应用程序仅将HBM用作内存而非计算 成本低廉的NVMe使数据中心更加高效
早期开源学术原型的后继 大加速器内存，BaM：“GPU-Initiated On-Demand High-Throughput Storage Access in the BaM System Architecture”，ASPLOS 2023：https://doi.org/10.1145/3575693.3575748 GIDS：“Accelerating Sampling and Aggregation Operations in GNN Frameworks with GPU-Initiated Direct Storage Accesses”，VLDB'24：https://arxiv.org/abs/2306.16384 目前是一个功能性原型，首次由cuGraph使用 易于集成到广泛使用的包管理器中 模板化的C++头文件库，专门用于应用程序对象 熟悉的程序员抽象 GPU缓存聚合到更少的IO 优化IO队列互动以适应O（100K） GPU线程
共同基础设施 在不透明实现之前的以头文件为中心的客户端库 内存由应用程序管理，SCADA提供API来分配和释放 从简单但关键的服务开始，如交换空间，然后扩展 CPU上的应用程序将所有数据从存储器读入GPU，就像以前一样 GPU线程将数据写入SCADA，并稍后将其读回 通过无限容量来缓解内存不足（OOM）问题 用于连续数组的API 我们期待您对下一个API和服务的反馈
应用程序开发人员和用户 分享对比GPU-CPU内存无法容纳的更多数据容量的需求 指定感兴趣的服务类型，例如数组、交换、键-值、VectorDB、数据框架？ 指定产品堆栈支持、部署模型的详细信息 基础设施开发人员 将SCADA层叠在上面，就像为NVSHMEM做的那样，例如Kokkos性能可移植框架 寻找新的细粒度计算和通信交错的途径，例如LLNL 存储供应商 支持更细粒度事务上的更高IOPs 参与实施和展示SCADA 特别感谢Micron、Kioxia、三星、西部数据等向我们提供驱动器以在实验集群（如ForMIO）中进行实验。
--【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/关注领域）